Skip to main content

Análisis y garantía de la calidad

En esta sección se presenta el feedback recibido sobre la calidad del proyecto, basado en las evaluaciones realizadas por el profesor y los compañeros durante las presentaciones. El enfoque principal es analizar la efectividad de las prácticas de garantía de calidad y el análisis del rendimiento del código. Se pretende identificar tanto los aspectos positivos como las áreas que requieren atención, con el fin de mejorar los procesos de desarrollo y asegurar la entrega de un producto final que cumpla con los estándares de calidad establecidos.

Feedback del día 14/03​

  • Debe incluir un enfoque detallado en la identificación de Code Smells, que son indicativos de posibles problemas en el código. Se recomienda el uso de herramientas como SonarQube para obtener métricas precisas que permitan evaluar la calidad del software de manera efectiva. Además, es crucial que la evaluación del rendimiento se realice de forma continua, incluyendo un análisis por cada sprint. Esto facilitará la observación de la evolución y las mejoras en la calidad del proyecto a lo largo del tiempo.

  • Se enfatiza que debe estar integrada en todos los procesos del desarrollo, y no limitarse a una revisión final. Es fundamental realizar pruebas estructuradas que aseguren la validación de elementos críticos, tales como APIs externas y sistemas de pago. Para lograr una verdadera garantía de calidad, la documentación correspondiente debe elaborarse desde el inicio del proyecto, asegurando que todos los aspectos sean probados y validados adecuadamente.

  • Es importante que la evaluación de calidad se enfoque en resolver las incertidumbres técnicas lo antes posible. Esto ayudará a evitar problemas en el futuro y asegurará un desarrollo más fluido. Aunque en algunos casos se destaca que la documentación de calidad fue bien elaborada, en otros se ha observado que no se ha puesto suficiente énfasis en garantizar la calidad desde el principio, lo que podría comprometer el éxito del proyecto.

Feedback del día 21/03​

  • Falta de métricas cuantitativas: En varios casos, no se han proporcionado datos numéricos que respalden el rendimiento del producto o su impacto. Sin estos, la presentación puede generar dudas sobre su viabilidad. Se recomienda incluir porcentajes de mejora, estimaciones de rendimiento o datos financieros claros.
  • Entrega tardía de la app a usuarios piloto: el retraso en el recibimiento de feedback de los usuarios piloto nos deja menos margen de tiempo de respuesta para corregir errores, por lo que es crucial comenzar con este proceso para ir realizando análisis de aceptación a lo largo del tiempo, y comprobar de esta manera si la opinión con respecto a la aplicación mejora o no.
  • Mejorar el estilo y consistencia del código, utilizando herramientas como Codacy para monitorizar la evolución, sintaxis y calidad del código de forma continua.

Feedback del día 04/04​

En el apartado de métricas y validación, se presentó una crítica constructiva sobre la gráfica de rendimiento del sprint 3. Se cuestionó la validez de los datos al ver que casi todos los miembros aparecen con un rendimiento del 10, lo cual puede ocultar problemas reales en la productividad. También se mencionó que los números laterales de la gráfica no se leían bien, dificultando la interpretación. Este tipo de observaciones apunta a una mejora en la visualización de datos y una reflexión más crítica sobre su significado real. Por otra parte, se felicitó a los equipos por la priorización del feedback recibido de los usuarios piloto, diferenciando adecuadamente entre errores técnicos, percepciones de UX y nuevas ideas de mejora. Esta categorización es clave para tomar decisiones informadas y mantener el enfoque del producto.

Feedback del día 11/04​

  • Documenta y explica los bugs hallados durante el testing
  • Si se realizan tests de estrés y performance para verificar la robustez del sistema, hacerlos en entornos que simulen el estado de despliegue sin estar en despliegue.

Feedback del día 25/04​

  • Análisis de riesgos poco desarrollado o genérico.
  • Falta de números específicos en KPIs y métricas.
  • Problemas técnicos en las demos (visibilidad, sonido, sincronización).
  • Destaca la necesidad de incluir análisis de estacionalidad y datos segmentados por ubicación.
  • Se menciona que la IA puede apoyar, pero con cuidado de las falsas alarmas.
  • Mostrar testeo del producto, identificación de puntos críticos y respuestas ante fallos.
  • KPI’s claros con umbrales numéricos.

Feedback del día 02/05​

Se resalta la importancia de tener un análisis claro del rendimiento del producto y del marketing, apoyado por KPIs y métricas relevantes (por ejemplo, a través de herramientas como Metricool). También se ha sugerido usar gráficos, aunque sea con pocos datos disponibles, para visualizar mejor la información. Las campañas, como las de influencers o redes sociales, deben tener un presupuesto detallado y se espera un plan claro sobre cómo se evaluará la efectividad y qué medidas se tomarán si los objetivos no se cumplen. En cuanto a la calidad del producto, se valoró positivamente cuando hubo un buen análisis de redes sociales e intentar conseguir una validación temprana por parte del equipo de trabajo.